Simulink Models for Autocode Generation∗

Suppose that you have developed a Simulink model of a virtual world, such as a wall or spring-mass system. We have seen how to choose the parameters of the virtual world so that it has desired properties. For example, we have seen how to choose the spring constant and inertia of the virtual spring-mass system so that it has a desired frequency of oscillation and satisfies a maximum torque limit. We also learned how to add damping to such a model to counteract the destabilizing effect of forward Euler integration. Once we develop a model of the virtual world that behaves correctly in simulation, it remains to implement this world in C code that can be executed on the MPC5553 microprocessor. Until now we have simply written the C code by hand, and have debugged any resulting errors as necessary. Such errors may arise from simple mistakes in implementing the force feedback algorithm, such as using incorrect parameter values or sign errors. They may arise in converting from physical units to units that the processor understands, such as duty cycle and encoder counts. Other errors arise from type conversions, such as those from signed to unsigned integers of different lengths. Furthermore, changes to the virtual world that are relatively easy to model in Simulink by adding additional blocks may require substantial work to code in C. The potential difficulties with hand coding control algorithms have not proven too burdensome in our lab exercises. However, many real world applications are much more complex, and the time taken to hand code an algorithm, with all the necessary debugging, may take months. Hence, if we already have an algorithm that works well in simulation, it would be advantageous to be able to generate C code directly from the Simulink model. Even if this code is not used in production, it may be used for testing on hardware, thus enabling the rapid prototyping paradigm for embedded software design. In this approach, control algorithms are first tested on a model of the system to be controlled. If the algorithms work correctly on the model, then autocode generation is used to obtain C code that can be tested on the mechanical hardware, thus enabling an additional level of testing and debugging to take place. The idea is that the algorithms will be known to work before they are coded into C, and thus any errors that arise must be in the coding, not in the original algorithm specification. Consider the Simulink diagram in Figure 1. As we have seen, with appropriate values of k, Jw, b, and T , we may successfully implement a virtual spring mass system that is a harmonic oscillator with specified period that satisfies the limit imposed on the reaction torque. The C code required to implement this system on the microprocessor must perform several tasks in addition to computing the reaction torque for a given wheel position, as shown in Figure 1. Wheel position must be obtained from the QD function of the eTPU. The duty cycle must be updated and sent to the PWM function of the eMIOS subsystem. Because wheel position comes from the eTPU in encoder counts, it must be converted into degrees. The reaction torque generated by the Simulink model is in N-mm, and must be translated into duty cycle. Variable type conversions must be performed. The eTPU and eMIOS peripherals on the MPC5553 must be initialized, just as we initialized them when hand coding in C. The various initialization and unit conversion tasks are tedious and error prone. We shall see that the best way to deal with these is to write Simulink subsystems that perform these tasks correctly. It will take some effort to do so, but once we are done, we will have a library of these subsystems that can be reused so that